Conversation
domfarolino
force-pushed
the
declarative-api-explainer
branch
from
b03b258 to
f8a6998
Compare
domfarolino
force-pushed
the
declarative-api-explainer
branch
from
f8a6998 to
77553aa
Compare
|
The proposal looks great! its exactly what i have in mind to support as additional tools via |
|
@bwalderman, @mfreed7, and @bvandersloot, could you take a look? |
|
|
||
| It's an open question as to whether [an | ||
| `outputSchema`](https://github.com/webmachinelearning/webmcp/issues/9) makes sense for declarative | ||
| WebMCP tools, and therefore if the `agentResponse` Promise passed to `SubmitEvent#respondWith()` |
There was a problem hiding this comment.
This also relates to the issue of who owns schema validation.
Inferring the output schema is impossible? So we'd have to permit it in the form attribute. Not impossible, but potentially very bulky.
| while `tooldescription` is analogous to | ||
| [`ModelContextTool#description`](https://webmachinelearning.github.io/webmcp/#dom-modelcontexttool-description). | ||
|
|
||
| The `toolautosubmit` [boolean attribute](https://html.spec.whatwg.org/C#boolean-attribute), lets the |
There was a problem hiding this comment.
I like this.
Here is where integration with visibility of form elements could also be interesting. If you require the user to review a form before clicking submit, why do you let agent fill things in that the user could not see.
Being in the control of the site, it can't be a prompt injection protection, but we can help a site build tools that an agent is less likely to misuse, and this fits that well.
|
|
||
| ### Input schema synthesis | ||
|
|
||
| TODO: The exact algorithms reducing a form, its form-associated elements, and *their* attributes |
There was a problem hiding this comment.
Devil is in the details here, but careful specification/testing should be sufficient to get something right.
| creates a new declarative WebMCP tool whose input schema is generated according to | ||
| [Input schema synthesis](#input-schema-synthesis). | ||
|
|
||
| We also introduce the new `toolparamname` and `toolparamdescription` attributes, which apply to form |
There was a problem hiding this comment.
Chromium currently uses toolparamtitle, not toolparamname
|
|
||
| ```html | ||
| <form toolname="search-cars" tooldescription="Perform a car make/model search" [...]> | ||
| <input type=text toolparamname="make" toolparamdescription="The vehicle's make (i.e., BMW, Ford)" required> |
There was a problem hiding this comment.
FYI Here's what Chromium currently have:
- The optional
toolparamtitleattribute maps to the json-schema property key. If omitted, the browser defaults to the input element’s name. - The optional
toolparamdescriptionattribute maps to the property description within the json-schema. In its absence, the browser uses the textContent of the associated HTML element but skips descendants that are labelable or, if no label exists, the aria-description.
There was a problem hiding this comment.
FYI Here's what Chromium currently have:
- The optional
toolparamtitleattribute maps to the json-schema property key. If omitted, the browser defaults to the input element’s name.
We don't fall back to the name, we just omit the title field in that case.
I think we probably don't need the toolparamtitle attribute at all. It's not currently part of the proposal, and I suggest keeping it that way. (We will still want to synthesize the title field in some cases, but we can do that based on <label>, etc.)
|
|
||
| ```html | ||
| <form toolname="search-cars" tooldescription="Perform a car make/model search" [...]> | ||
| <input type=text toolparamname="make" toolparamdescription="The vehicle's make (i.e., BMW, Ford)" required> |
There was a problem hiding this comment.
I think you'd want to remove toolparamname for now, and use name="model" and name="make" instead.
| and when its invocation is canceled. Some open questions: | ||
|
|
||
| > [!WARNING] | ||
| > Should these events fire for imperative tool call invocations as well? |
There was a problem hiding this comment.
Are these being added so that web developers can do javascript things when a declarative tool is called? What would be the reason to do this vs. use the submit event handler with preventDefault()?
| > Should these events fire for imperative tool call invocations as well? | ||
|
|
||
| > [!WARNING] | ||
| > For declarative, should they be fired at `Window` or at the `<form>` that registered the tool in |
There was a problem hiding this comment.
My vote would be for firing on the element that registered the tool. This makes it a lot easier to associate event handlers with tools on pages that have many declarative tools.
There was a problem hiding this comment.
Yep, I think I agree with this! Mind if we leave it as a WARNING for now since it reflect's Chromium's behavior, and then we can get rid of the warning once Chromium starts firing them at the element? I just want to make sure things don't get too out of sync.
There was a problem hiding this comment.
One complicating factor: if we consider firing these events for the imperative API as well, it becomes confusing that they sometimes fire on Window, and sometimes fire on <form> elements. I think it we had a dedicated Tool interface that inherited from EventTarget to represent imperative tools, then we could have a policy "these events fire directly on the tool: Tool for imperative tools, and <form> for declarative tools". Without such an interface, it might be weird to separate the firing. So let's discuss in a separate issue.
Co-authored-by: Brandon Walderman <brwalder@microsoft.com>
7 participants
This is a follow-up of #26 to address #22. Note that #26 has been superseded by this PR, per #26 (comment).